This is a first approximation of a CMake based build for this
repository.  The intent here is to localize the build rules for the
repository to allow it to be consumed during the build of the toolchain.
This allows the source list to be maintained in the repository as the
source of truth rather than be explicitly listed in the swift
repository.

For general purpose development, the SPM based build is recommended.
Unless there is a specific need for the tests to be included, testing
should be done via the SPM build.

This change is sufficient to build the content though does not perform
the install or export steps which will be required to consume the
results in the Swift build.

Example invocation:
~~~
cmake -B S:\b\16 ^
      -D CMAKE_BUILD_TYPE=Release ^
      -D ArgumentParser_DIR=S:\b\10\cmake\modules ^
      -G Ninja ^
      -S S:\SourceCache\swift-experimental-string-processing
cmake --build S:\b\16
~~~

Previously we followed PCRE's parsing of this syntax
such that it may either be an octal sequence or
backreference depending on a list of heuristics.
However this model is complicated and not particularly
intuitive, especially as there are other engines
that disambiguate using subtly different rules.

Instead, always parse `\DDD` as a backreference,
unless it begins with `0`, in which case it is an
octal sequence. This matches ICU and Java's
behavior. Once we start validating group references,
we can then start emitting an error on invalid
backreferences using this syntax, and suggest
prefixing with 0 if an octal sequence is desired.

Co-authored-by: Michael Ilseman <michael.ilseman@gmail.com>

Lots of ME stuff was annotated with vestigial public

build: add a CMake based build

Allow the C++ lexer to form a tok::regex_literal.
This avoids generic fallback behavior, and better
allows for things like code completion. The test
case for this will be in the C++ repo.

If a single quote is encountered with a prefix of
either `(?`, `(?(`, `\k`, `\g` or `(?C`, continue
to scan ahead to a closing `'`. Such prefixes would
not be valid endings for a regex literal anyway,
and this lets us handle the single quote variant
of their syntax.

For the group name cases, further refine this
skipping behavior by only skipping over characters
that could possibly appear in that case. This
improves diagnostic behavior by ensuring we don't
go wandering off into Swift code.

Change the default script property behavior for an
unqualified value e.g `\p{Greek}` from
`\p{Script=Greek}` to `\p{Script_Extension=Greek}`.
This is arguably the more intuitive behavior, and
matches what Perl does.

Moved the note about syntactic support not meaning run-time support to intro

Adds a test with a `SemanticVersion` type that conforms to
`CustomRegexComponent`.

Document specially integrated modules and integration process.

This enables the `\y` and `\Y` anchors in regex literals and
`Anchor.textSegmentBoundary` in the DSL.

Note: This also includes `UnicodeScalar` conformance to
`RegexProtocol`, which acts like Unicode scalar literals in
regex literals.

Co-authored-by: Nate Cook <natecook@apple.com>

…t Machine

Here is the reduced test case:

    func foo<C : Collection, R : Sequence>(_: C, _: R) where C.SubSequence == Substring, C.Element == R.Element {}

The Requirement Machine produces a valid but different minimization than the
GenericSignatureBuilder for this signature, which flags the assert since
right now we run both and compare the results:

    error: compile command failed due to signal 6 (use -v to see invocation)
    RequirementMachine generic signature minimization is broken:
    RequirementMachine says:      <C, R where C : Collection, R : Sequence, C.[Sequence]Element == R.[Sequence]Element, C.[Collection]SubSequence == Substring>
    GenericSignatureBuilder says: <C, R where C : Collection, R : Sequence, C.[Collection]SubSequence == Substring, R.[Sequence]Element == Character>

Radar tracking the fix: rdar://problem/89791117

…89791117

Tweak a few generic signatures to work around a bug in the Requirement Machine